The advent of business-to-business (B2B) electronic commerce has led to the development of technologies for the automated payment transactions between buyers and sellers engaged in electronic commerce. In particular, mechanisms have been promulgated for the initiation of payments related to B2B e-commerce transactions using the Internet. One such technology is the Eleanor initiative. Eleanor is a set of specifications for implementing interoperable B2B electronic payment services which may be communicated between the parties using the Internet. Eleanor is promulgated by Identrus LLC, New York, N.Y., and the Eleanor specification may be obtained through it.
In a transaction conducted in accordance with the Eleanor mechanism, transactions are conveyed in messages in accordance with the Eleanor specifications. In any transaction, the entities that may participate are a buyer (“BU”), a seller (“SE”), a seller financial institution (“SFI”) and a buyer financial institution (“BFI”). Note that in a transaction, a particular financial institution might be acting on behalf of both the buyer and seller. That is, a particular buyer and seller pair could have the same financial institution. The entity on whose behalf the financial institution is acting may be referred to as the “role” of the institution in any given transaction.
Additionally, transactions may be initiated by either the seller or buyer. If initiated by the buyer, the transaction may, but need not, include securely signed information from the seller. (For the purposes herein, a securely signed information from the seller may be understood to be a digital signature which may be based on a public-key algorithm, and a trusted certification authority; the details of the signing algorithms are not required). Note that the source of a particular message may be any one of entities participating in a transaction, that is a buyer, seller, buyer's financial institution or seller's financial institution, and this may be independent of the initiator of the transaction. The initiator of the transaction may be signified in a message by the “model.” If the transaction is initiated by the Seller, the model may be referred to as a seller financial institution model (“SFIM”). Similarly, if the buyer initiated the transaction, the model referred to as the buyer financial institution model (“BFIM”). There may be two submodels of the buyer financial institution model depending on whether the transaction is initiated by the buyer and signed by the seller, the buyer financial institution model with seller signature (“BFIMsig”) or, alternatively if unsigned by the seller, the buyer financial institution model without seller's signature. The model may be used, among other things, to allow a financial institution to distinguish the order in which messages must be forwarded between itself, its subscriber, or other financial institutions, or the types and order of the validity checks it must perform. Requests for payment in the BFIM model are usually instructions from a Buyer for the Buyer's financial institution to release money.
These requests may be in the form of payment order from the Buyer requesting the BFI to execute a credit payment to the Seller. In particular, a payment order may be made subject to a condition (conditional payment order) whereby the payment will not be released until the conditions have been met, or waived.
The payment condition may be in any of several status. For example, in the Eleanor Specification, discussed hereinabove, there are seven condition status: Registered, CDPProcessing, Cancelled, Waived, Discharged, Expired and Failed. Different parties, for example, buyers and condition discharging parties can concurrently access a payment system and submit requests which may trigger condition status transitions. (A condition discharging party may be a party that, for a particular conditional payment, may discharge the condition, that is, “inform” the payment system that the particular condition has been met. The condition discharging party may be, but is not necessarily, the buyer.) The buyer may submit a cancel request to transition the status to cancelled status. If, for example, these two events occur substantially concurrently, the operating system will select one to execute, and the other will wait until the first change in status is complete. The subsequent execution of the second event may fail because of the change in status due to the execution of the first. This may present a performance bottleneck to the payment system.
Therefore, there is a need the art for mechanisms to prioritize the processing of conditional payment requests in an electronic payment system.